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SIMULATION SYSTEM AND COMPUTER- IMPLEMENTED METHOD FOR 
SIMULATION AND VERIFYING A CONTROL SYSTEM 

Dcocript ion 

FIELD OF THE INVENTION 

The present invention relates to a simulation system for 
computer- implemented simulation and verification of a control 
5 system under development as well as a computer- implemented 
method for simulating and verifying a control system under 
development. More particularly, the present invention relates 
to the so-called rapid prototyping of a control system for 
dynamic systems such as vehicles, aircrafts, ships, etc. as 
10 well as parts thereof. Further, the present invention relates 
to a computer program product with a computer- readable medium 
and a computer program stored on the computer- readable medium 
with program coding means which are suitable for carrying out 
such a process when the computer program is run on a computer. 

15 

State of the Art 
BACKGROUND INFORMATION 

Rapid prototyping of control systems is commonly used in the 
automotive industry, aviation, etc. for early verification of 

20 the correct, functional and real-time behavior of a control 
system under development. Like this, control strategies and 
algorithms for dynamic systems such as vehicles or parts 
thereof can be tested under real -world conditions without 
requiring the existence of the final implementation of the 

2 5 control loop. 

A rapid prototyping system usually is characterized as being a 
hybrid hardware/software system, in general consisting of the 
following main components: 
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• a simulation target, consisting of one or several 
simulation processors with corresponding memory modules, 
each running basically a portion of a model of the 
control system under development, 

5 

• input interfaces composed of signals being fed by the 
plant (the outside world being controlled) , 

• output interfaces composed of signals feeding the plant, 
10 and 

• communication interfaces for downloading the module from 
a host (often a personal computer) onto the simulation 
target, controlling the simulation experiment (start and 

15 stop commands, etc.), measuring and calibrating module 

signals and parameters, respectively. 

Figure 1 ahowo illustrates a conventional simulation system 10 
at the model level ao known from the prior art . Technically 
20 the lenown simulation system 10 comprioco includes one or more 
simulation processors with corresponding memory modules on 
which portions 12a, 12b, 12c of a model of the control system 
under development (or so-called sub-models) are run. The 
simulation system 10 further comprioco includes an input 

2 5 interface 13a and an output interface 13b for exchanging 

signals with the so-called outside world. Finally, the 
simulation system comprioco includes a communication interface 
for downloading the module from a host onto the simulation 
target, controlling the simulation experiment, measuring and 

3 0 calibrating module signals and parameters, respectively. 

Figure 1 is at the model level, not at the technical level. 
With 14 are stimuli signals named, used where no physical 
input signals are available. Separate from this is the 
communication interface later described with regard to figure 
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1 



Figure 3. The inventive communication interface could hereof 
could be added into the figure Figure 1 structure if desired. 

Signals of the input and output interfaces can be analog 
5 (e.g., temperature or pressure sensor) or digital (e.g., 
communication protocol such as CAN) . Within simulation 
experiments, the rapid prototyping system is used as integral 
part of the control loop, just the way finally the controller 
(electronic control unit) will be. 

10 

The preparation of a rapid prototyping experiment in general 
consists of the following steps: 

1. creation of a mathematical model of the control system, 
15 for instance, by means of a behavioral modeling tool (such as 

MATLAB 0 / Simulink^ 1 or ASCET-SD 2 ) or by hand, 

2 . manual transformation (hand coding) or automated 
transformation (code generation) of the model into program 

2 0 code in some high-level programming language (C, for 
instance) , 

3. compilation and linkage of the program code into an 
executable, 

25 

4 . download of the executable from the host onto the 
simulation target via the host- target communication interface, 
and 

30 5. setup and invocation of the experiment from the host via 
the communication interface. 

Frequently, several model parts (called modules in the 
following) from one or several sources (e.g., behavioral 
35 modeling tool, hand-written C code) are to be integrated with 
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each other, so as to compose an entire control system's model. 
The communication among modules 12a, 12b, 12c as well as 
between modules and input or output interfaces 13a, 13b 
(likewise considered as modules in the following) is performed 
5 via signals connecting input and output ports, depicted as 
circles in Figure 1. 

Conventionally, this communication is achieved by sharing the 
very same memory location (the same high-level language 
10 variable) for ports being connected with each other, where one 
module writes the current value of the signal into the given 
memory location and the other module reads from it. 

In order to achieve this, the transformation of the model into 
15 executable code needs to be performed in a manner depending on 
the actual interconnection scheme, denoting that output port a 
of module A be connected with input port b of module B, for 
instance. In this example, both ports a and b would need to be 
statically mapped onto the very same memory location on the 
2 0 simulation target so as to enable inter-module communication. 

With this conventional static interconnection approach, 
signals connect ports with each other in an inseparable 
manner. Whenever one or several connections between signals 

25 are to be established, modified or cut off, the entire process 
of model-to-code transformation, compilation and linkage, 
executable download, experiment setup and invocation needs to 
be performed. For real -world models, this process is very time 
consuming and may take up to several tens of minutes or even 

30 more. Especially when correcting a faulty connection being 
made inadvertently, current turn-around times are far too 
large. Further, as soon as the experiment has been downloaded 
and started, connections cannot be altered, added, or removed 
any longer. 

35 
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As said before rapid prototyping of control systems is 
commonly used in the automotive industry, aviation, etc., for 
early verification of the correct functional and real-time 
behavior of a control system under development. Like this, 
control strategies and algorithms for dynamic systems such as 
vehicles or parts of them can be tested under real -world 
conditions without requiring the existence of the final, 
implementation of the control loop. 

Following rapid prototyping, the control system 1 s final 
software is being developed. The result is a production 
quality software executable for the electronic control unit 
being targeted. Particularly, this phase involves coding the 
software, testing and observing it under real -world 
conditions, and calibrating its parameters, so as to tune the 
behavior according to given requirements. The basis for the 
latter two steps are measurement and calibration (M & C) 
technologies . 

M 8c C technologies could be used with a host/target 
architecture where 

• the host in general is the PC running the M & C tool, 

• the target mostly is an embedded computer running the 
controller, e.g., 

• dedicated experiment hardware for rapid prototyping 
or 

• an electronic control unit (ECU) for software 
development , and 

• host and target are connected with each other via 
dedicated M & C communication interfaces. 
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Of both host and target, several instances may be involved in 
a distributed M & C system. 

The M 8c C tool usually performs tasks such as 

• measuring the values of variables in the control system's 
software, displaying them in form of graphical 
instruments such as scopes, dials, gauges, or numerical 
displays, and logging them onto disk, and 

• calibrating the values of parameters, e.g., scalars, 
arrays, or interpolated maps, by displaying them in form 
of graphical input devices such as sliders, buttons, 
knobs, curves and 3D maps, or numerical displays, and 
sending any alterations of the current value made by the 
user down to the control system's software. 

M & C tools rely on a number of standardized M & C interfaces 
being either true or de-facto standards, especially in the 
automotive industry. The availability of those interfaces can 
be assumed in automotive hardware for both rapid prototyping 
or software development, especially for A- step and B-step 
ECUs. In this context, experiment environments as used for 
rapid prototyping are considered M & C tools as well, though 
of restricted or partly different functionality. 

M 8c C interfaces need to be supported by both software and 
hardware, on the host as well as on the target. Roth are 
connected with each other via some physical interconnection 
running some communication protocol. The M & C tool on the 
host in general uses software drivers for this purpose, while 
the target hardware runs dedicated protocol handlers. Examples 
for M & C protocols are COP, XCP, KWP2000, or the INCA 1 , 

1 INCA, LI and Distab protocol are communication protocols proprietary to 

ETAS GmbH (a Robert Bosch GmbH subsidiary) . 
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ASAPlbVLl 1 , and Distab 1 protocols. Physical interconnections 
are, e.g., CAN # ETK 3 , Ethernet, FlexRay, USB, K-Line, WLAN 
(IEEE 802.11), or Bluetooth. For the development of embedded 
control systems, often behavioral modeling tools are employed, 
5 such as ASCET 4 , MATLAB^/Simulink 05 , Statemate MAGNUM™ 6 , and UML 
or SDL tools. These tools in general provide some graphical 
user interface for describing a control system 1 s structure and 
behavior by mcano of block diagrams, state machines, message 
sequence charts, flow diagrams, etc. Like this, a mathematical 

10 model of the control system may be created. Once the model is 
available, an automated transformation (code generation) of 
the model into program code in some high-level programming 
language (C, for instance) and finally in an executable 
program can be performed, either for rapid prototyping or as 

15 the production quality ECU software. 

As a convenient way of testing and debugging a control 
system 1 s software or the model itself, many modeling tools 
provide mcano device (s) for animating the model during its 
20 simulation or execution by visualizing its behavior, e.g., by 

• displaying current signal values on top of signal lines, 

• displaying them in a graphical instrument, or 

25 

• highlighting active and previously active state machine 
states directly within the modeling environment. 



2 The ASAPlb communication protocol has been standardized by the AS AM 
association . 

3 The ETK is an ETAS proprietary physical interconnection. 

4 ASCET is a product family by ETAS GmbH. 

5 MATLAB®, Simulink®, and Real-Time Workshop® are registered trademarks of 
The Mathworks , Inc . 

6 Stalemate MAGNUM™ is a registered trademark of I-Logix, Inc. 
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Like this, no separate experiment environment is needed. 
Further, some tools provide the possibility of directly 
calibrating parameter values via the modeling environment, 
using the normal user interface of the modeling tool. 

5 

Ao of today, — thio This conventional approach of model 
animation and in-model calibration is available on experiment 
hardware only, for instance, on a PC running both the modeling 
tool and the experiment at the same time (off-line simulation) 
10 or together with dedicated rapid prototyping hardware (on-line 
simulation) . Further, proprietary communication protocols are 
used, e.g., the external mode protocol of MATLAB 0 / Simulink 0 or 
the LI protocol in ASCET. 

15 This conventional approach as described above is shown in 
Figure 6 . 

The conventional approach to date is known to be employed by 
rapid prototyping systems such as those of ETAS GmbH (ASCET- SD 
20 product family), The Mathworks, Inc. (MATLAB^/Simulink 0 , 
Real-Time Workshop®, xPC Target) and presumably others. 

Such a static interconnection as known from the prior art 
conventional is visualized in Figure 2a. Figure 2a shows a 
25 first module 12d and a second module 12e which are sharing a 
variable which is stored in a static memory location 81. 

SUMMARY 

It io therefore an object Example embodiments of the present 

30 invention [ [to] ] may provide more flexible interconnection of 
hitherto static connections so that a simulation already being 
performed can may be easily corrected, intercepted or 
modified. It io a further object Example embodiments of the 
present invention [ [to] ] may improve communication between 

35 single components of a simulation systems as well as 
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communication between single modules of a simulation model for 
providing a rapid prototyping of a control system of a 
vehicle . 

5 Thcoc objccto arc achieved by propooing a oimulation oyotcm 

and a computer implemented method for oimulating and verifying 
a control oyotcm with the fcaturco of the respective 
independent claimo . 

10 Advantages of the invention 

In contrast to the approach according to the prior art 
conventional approaches as described above, the dynamic 
interconnection approach of the prcocnt invention doco hereof 

15 may not rely on interconnection scheme specific model-to-code 
transformation. Instead, this transformation is totally 
independent of the actual module interconnections being used. 
Rather, inter-module communication is performed in an explicit 
manner by using distinct memory locations instead of shared 

20 ones and copying or replicating signal values from one memory 
location to another when needed. 

Therefore advantagcouoly a simulation system for computer- 
implemented simulation and verification of a control system 

2 5 under development is ohown provided , wherein the simulation 

system comprioing including a generic model animation and in- 
model calibration interface, which uses measurement and 
calibration technologies with a host-target architecture, 
wherein the host contains at least one respective modeling 
30 tool and on the target software of the control system is 
executed. Aloo part of the invention io a A computer- 
implemented method is for simulating and verifying a control 
system under development by mcano of such a simulation system 
and a computer program with program coding mcano devices which 

3 5 are suitable for carrying out this method, when the computer 
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program is run on a computer and also a computer program 
product with a computer- readable medium like a RAM, DVD, CD- 
ROM, ROM, EPROM, EPROM, EE PROM , Flash, etc. and a respective 
computer program stored on the computer- readable medium. 

5 

In addition in a preferred embodiment a A target server [ [is] ] 
may be used to connect the modeling tool with the target and 
the target server contains a protocol driver of a 
communication protocol used for communication with the target. 

10 

In an additional embodiment a A simulation system io shown 
comprioing may include a plurality of simulation processes 
with corresponding memory and interface modules, which modules 
comprise include distinct memory locations for inter-module 

15 communication and wherein simulation is performed by running a 
control system simulation model, the simulation model 
comprising including a number of sub-models being performed on 
one of the plurality of modules, respectively, wherein at 
least some of the modules are dynamically reconf igurable for 

20 communication via distinct memory locations. 

Also a part of the invention io a A host of a simulation 
system is for computer- implemented simulation and verification 
of a control system under development, the host comprioing 
25 including a generic model animation and in-model calibration 

interface, which uses measurement and calibration technologies 
for a host- target architecture, whereby the host containo 
includes at least one respective modeling tool and a target 
server to connect the modeling tool with the target. 

30 

Since the interconnection scheme is not reflected by the mere 
simulation executable, it needs to be passed on to the 
simulation target differently. This is achieved by dynamically 
setting up the actual module interconnections via the host- 
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target communication interface during experiment setup, after 
having downloaded the executable . 



The exchange of signal values will be performed according to 
5 the respective interconnection scheme. No implicit naming 
conventions or the like as with the static memory sharing 
approach are required. Rather, the current value of a given 
signal is distributed from an output port to any connected 
input port by explicitly reading the value from the memory 
10 location associated with the output port and then replicating 
it to any memory location corresponding to a relevant input 
port . 

The Certain major advantaged aspects (which will be declared 
15 described in more detail in the description) of this approach 



are : 



20 



The availability of required interfaces in form of M & C 
technology in the relevant hardware and software eaft may 
be assumed since the approach is based on standardized 



solutions . 



25 



There is no need for porting any software onto each 
combination of target hardware and physical 
interconnection, which otherwise constitutes tremendous 



efforts . 



30 



The same modeling tool interface eaft may be used for 
model animation and in-model calibration during off-line 
and on-line experiments as well as during ECU operation. 



There is neither memory nor run- time overhead on the 
target hardware since no additional proprietary protocol 



handler is needed. 



35 
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• There is no bandwidth overhead on the physical 
interconnection since no additional proprietary protocol 
i s run . 

5 • The run- time behavior of the model on the target hardware 
is unaffected since no background tasks or similar are 
needed for communication. 

• Hence, especially ECUs (in general providing very low 
10 memory as well as run-time resources and intrinsically 

supporting M & C technologies on large numbers of 
hardware and interface variants) are ideally supported. 

• A log & replay off-line debugging functionality is 
15 supported. 

• The turn-around times after altering the interconnection 
scheme are reduced significantly since the time consuming 
process of model-to-code transformation, compilation and 

2 0 linkage, and executable download needs not he repeated. 

This strongly supports the actual application of rapid 
prototyping . 

• Signals connecting ports eaR may be established, 

2 5 modified, or removed even during a running experiment 

without perceptible delay. This enables completely new 
possibilities of use such as the following: 

• correcting faulty connections on the fly, even 
30 without interrupting the experiment, 

• gradually setting up an experiment by putting 
portions of the entire model into operation little 
by little while continually establishing the final 

35 interconnection scheme, 
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spontaneously stimulating the model by establishing 
connections to its input ports, 



5 • switching an input port from a predefined stimulus 

module over to a real -world input signal, 

• comparing a number of implementation variants of the 
same module running in parallel by alternatively 

10 switching their outputs to the plant, or 

• swapping inputs or outputs to the rapid prototyping 
system virtually on the tool level, instead of first 
pulling out and again plugging in physical cable 

15 connections . 

Therefore, according to the invention a simulation model is 
run to simulate and verify a control system during 
development, the simulation model comprioco includes a number 

2 0 of sub-models which are run on the same or different nodes 

(processors) of a simulation system. Communication between the 
respective modules of the simulation model as well as the 
simulation system is performed via distinct and separate 
memory locations, the modules being dynamically connected with 

25 each other. 

In a preferred embodiment of the invention, — fc-he The data 
and/or signals a^e may be replicated consistently by mcano of 
a cross-bar switch. Prcf crably For example , this replication 
30 is performed under real time conditions. 

In a further embodiment of the invention, — the The modules may 
interconnect automatically via interconnection nodes and 
replicate data. 



35 
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A consistent replication of data under real-time circumstances 
or conditions may be done via communication variables. The 
cross-bar switch as mentioned above provides mcano for 
consistently copying values of output signals to communication 
5 variables after reaching a consistent state. Further, the 

cross-bar switch provides mcano for consistently passing these 
values to connected input signals before the respective 
modules continue computation. Depending on the respective real 
time architecture of the simulation system and/or the set-up 

10 of the real-time operating system a consistent copy mechanism 
may be achieved by atomic copy processes, blocking interrupts^ 
etc . or the like. Under certain circumstances being determined 
by the respective real-time environment settings, signal 
variables or communication variables may be obsolete and then 

15 could may be optimized away for higher performance. 

According to an alternative embodiment of the invention, — a A 
distributed approach could may be used for dynamic 
reconfiguration of module interconnections instead of the 
20 central approach as described above. In this alternative 

embodiment arrangement , ports could may connect themselves to 
their respective counterparts and be responsible for signal 
value replication. 

2 5 The invention aloo covcro a A computer program with program 

coding mcano which arc devices may be suitable for carrying 
out a process according to the invention as aubacribed 
described above when the computer program is run on a 
computer. The computer program itself as well as stored on a 

3 0 computer-readable medium is claimed described . 

Further features and embodiment o aspects of example 
embodiments of the present invention will become apparent from 
the dcacription and the accompanying drawings are described 
3 5 below with reference to the appended Figures . 
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It will should be understood that the features mentioned above 
and those described hereinafter eeft may be used not only in 
the combination specified but also in other combinations or on 
5 their own, without departing from the spirit and scope of the 
prcocnt — invention hereof . 

The invention io ochcmatically illustrated in the drawingo by 
mcano of an embodiment by way of example and io hereinafter 
10 explained in detail with reference to the drawingo. — It ia 

undcrotood that the dcocription io in no way limiting on the 
ocopc of the prcocnt invention and io merely an illuotration 
of a preferred embodiment of the invention. 

15 Brief dcocription of the drawingo 

In the drawingo, 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic block illustration of a simulation 

2 0 system at the model level of the prior art ao well ao of the 

invention;^ 

Figure 2a is a schematic illustration of a conventional static 
interconnection of the prior art [ [ ; ] ] . 

25 

Figure 2b io a preferred illustrates an example embodiment of 
a dynamic interconnection according to the present 
invention [[;]]_-_ 

3 0 Figure 3 io a preferred illustrates an example embodiment of a 

simulation system according to the present invention using a 
dynamic interconnection according to Figure 2b[[;]] -L 

Figure 4 [ [is] ] illustrates an example of a consistent 
35 replication under real-time circumstances via communication 
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variables according to an example embodiment: of the present: 

i nve n t i on-; — ancL _ 

Figure 5 ia an alternative illustrates an example embodiment 
5 of an interconnection scheme according to the present 
invention. 

Figure 6 showo illustrates architecture of model animation and 
in-model calibration . 

10 

Figure 7 [[is]] illustrates an example for an inventive a 
model animation and in-model calibration approach with a 
target server. 

15 Embodiments 

DETAILED DESCRIPTION 

According to example embodiments of the present invention and 
in contrast to £4*e conventional static connection known from 
the prior art as described above with reference to Figure 2a, 

20 a dynamic interconnection approach via distinct memory 
locations is provided. The principles of the dynamic 
interconnection according to the invention , is visualized in 
Figure 2b wherein data 81a of a first module 2d are copied or 
replicated by mcano of dynamic replication 20 in a distinct 

25 memory location of a second module 2e as according data 81a' . 

Several architectures underlying the dynamic reconfiguration 
approach may be conceived provided . With reference to Figure 
3, a firot an example for a simulation system 30 according to 
30 the invention is described in the following as the so-called 
central approach. 

The main component of the central approach simulation system 
30 is a so-called cross-bar switch 10 with an interconnection 
35 scheme 11. The simulation system 30 further comprioca includes 
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a plurality of modules 2a, 2b, 2c, an input interface 3a, an 
output interface 3b, a stimuli generator module 4 as well as a 
real-time operating system 7. 

5 As visualized by the double headed arrows in Figure 3, all 
components of simulation system 3 0 are interconnected with 
each other via the cross-bar switch, the interconnection 
scheme 11 defining which input and output ports of modules on 
the simulation target are connected with each other. The 
10 interconnection scheme corresponds to the totality of 

connections in a block diagram wherein each block corresponds 
to one of the modules being integrated on the simulation 
target 30. 

15 The interconnection scheme 11 could may be conceived provided 
as a two-dimensional switch matrix wherein both dimensions 
denote the modules 1 ports and the matrix values define whether 
the respective ports are connected with each other (and 
possibly the signal flow direction) . 

20 

A simulation host 5 is connected with the cross-bar switch 10 
via a host -target communication interface 6 and constitutes 
the human-machine interface to the rapid prototyping system. 

2 5 The host 5 enables provides the configuration and 

reconfiguration of the interconnection scheme, preferably 
e.g., supported by some graphical user interface. 

The host-target communication interface 6 connects the 

3 0 simulation host 5 with the simulation target 30. In general, 

it is based on some wired or wireless connection (serial 
interface, Ethernet, Bluetooth, etc.) and standardized or 
proprietary communication protocols (e.g., ASAPlb, LI). It 
provides at least the following functionality: 

35 
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• download of the simulation executable from the host 5 to 
the simulation target 30 and 

• download of configuration data defining the 
5 interconnection scheme 11. 

Further, it may provide functionality for 

• controlling the experiment, e.g. for starting and 
10 stopping the simulation, 

• measuring values of model signals, interconnection 
signals, and input or output signals, 

15 • calibrating model parameters, etc. 

The cross-bar switch 10 runs on the simulation target and is 
connected with 



20 • the simulation host 5 via the host-target communication 
interface 6, 

• modules 2a, 2b, 2c representing model portions or sub- 
models of the control system under development, 

25 

• modules 3a, 3b representing input and output interfaces 
to the control system's plant, 

• modules 4 serving as stimuli generators to the model, and 

30 

• preferably e.g., a real-time operating system 7 
underlying the simulation experiment. 



Before starting a simulation experiment, the initial 
35 interconnection scheme 11 is downloaded from the host 5 via 
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the host-target communication interface 6 into the cross-bar 
switch 10. 

During a running experiment, the cross-bar switch 10 performs 
5 the actual communication among modules and components by- 
copying signal values from output ports to input ports. The 
way manner in this replication process is performed is defined 
by the interconnection scheme 11. 

10 The interconnection scheme 11 eaft may be reconfigured after 

interrupting or even during a running simulation. Thus, module 
interconnections eaft may be altered on the fly, without 
perceptible delay . 

15 Referring now to Figure 4, a preferred an alternative of a 

transmission of signals and/or data according to the invention 
is illustrated. By mcano of dynamic replication 40, signal 
and/or data values 82a, 82e of a first module 2f eat* may be 
buffered as communication variables 82b, 82 f, respectively, in 

20 distinct memory locations. By mcano of further dynamic 
replication 40, second and third modules 2g, 2h receive 
respective signal and/or data values 82c, 82g and 82d, 82h, 
respectively . 

2 5 Thus, data consistency within a real-time environment is 

cnourcd provided . Each module 2t, 7g, 2h may compute at^ e.g.^ 
a different rate or upon interrupt triggers, and data 
replication 4 0 is performed by mcano of communication 
variables 82b, 82 f buffering the current signal values. Thus, 

3 0 the values of several output signals which as a whole 

constitute a valid state are guaranteed to be copied in a 
consistent manner such that modules being fed by these output 
signals may themselves rely on a valid state. 
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As already mentioned above, the cross-bar switch 10 provides 



mcano for 



5 



consistently copying values of output signals to 
communication variables after reaching a consistent state 



and 



10 



consistently passing these values to connected input 
signals before the respective modules continue 
computation. 



The consistent copy mechanism as described may be achieved by 
atomic copy processes, blocking interrupts or the like , etc. , 
depending on the underlying real-time architecture and 
15 operating system. 

Under certain circumstances being determined by the respective 
real-time environment settings, signal variables or 
communication variables may be obsolete and then could may be 
20 optimized away for higher performance. 

The above -described dynamic reconfiguration approach could may 
be extended by signal conditioning facilities. In order to 
achieve this, each signal value may be influenced during 
25 inter-module communication in a pre-defined manner after 

reading the original value from the source memory location and 
before writing to the target memory location. 

Possible signal conditioning operations are: 



30 



implementation formula adaptation (e.g 
modification, saturation) or 



• / 



scale or offset 
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• basic mathematical operations (e.g., sum, difference, 

multiplication of signals, mapping via look-up table or 
characteristic with interpolation, constant value) . 

5 The kind of operation being applied and the respective 

parameters are considered as being part of the interconnection 
scheme. Each of them eeft may be configured and reconfigured in 
a dynamic manner, as eaft may module interconnections. This 
enhancement may greatly widcno widen the usefulness of the 
10 dynamic reconfiguration approach. 



Referring now to Figure 5, a distributed approach for dynamic 
reconfiguration of module interconnections which could may be 
used instead of the central approach employing a distinct 
15 cross-bar switch component on the target is described. Rather 
than having a central component copy signal values, ports 
could "connect themselves" to their respective counterparts 
and be responsible for signal value replication. 

2 0 For instance, this could may be achieved by having input ports 
92a, 92b and 93b of modules 2j and 2k register themselves at 
output port servers 91a, 91b of module 2i upon connection, 
each of which represents a given output port. Communication 
could may be performed either following a pull approach (input 

25 port queries signal value) or a push approach (multi-cast of 
signal value, invoked by output port) . Thus, the intelligence 
for value replication is distributed over the system's 
components instead of concentrating it in a central cross-bar 
switch component . 

30 

Generic Model Animation and In-Model Calibration Interface for 
Rapid Prototyping and Software Development (Figure 7) 



A generic model animation and in-model calibration interface 
35 for rapid prototyping and software development, which uses 

NY01 1164955 21 MARKED-UP VERSION OF THE 

SUBSTITUTE SPECIFICATION 



measurement and calibration technologies with a host -target 
architecture and a respective simulation system and method. 



The Basic Concepts 

5 

In contrast with the described approach in the state of the 
art, the generic model animation and in-model calibration 
approach being the subject of this invention does not rely on 
either dedicated simulation or rapid prototyping hardware or 
10 proprietary communication protocols. Instead, standard M & C 
technology is used. 

As oaid described before tfee certain major advantagco aspects 
of this approach are: 

15 

• The availability of required interfaces in form of M & C 
technology in the relevant hardware and software eeR may 
be assumed since the approach is based on standardized 
solutions . 

» There is no need for porting any software onto each 
combination of target hardware and physical 
interconnection, which otherwise se constitutes 
tremendous efforts . 

• The same modeling tool interface eaa may be used for 
model animation and in-model calibration during off-line 
and on-line experiments as well as daring ECU operation. 

30 • There is neither memory nor run-time overhead on the 

target hardware since no additional proprietary protocol 
handler is needed. 



20 



25 
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• There is no bandwidth overhead on the physical 
interconnection since no additional proprietary protocol 
is run. 

5 • The run- time behavior of the model on the target hardware 
is unaffected since no background tasks or similar are 
needed for communicat ion . 

• Hence, especially ECUs (in general providing very low 
10 memory as well as run-time resources and intrinsically 

supporting M & C technologies on large numbers of 
hardware and interface variants) are ideally supported. 

• A log Sc replay off-line debugging functionality is 
15 supported. 

• For generic model animation, these standard interfaces 
are used for animating the control system's software, or 
a model thereof, or visualizing its behavior. 

20 

• For in-model calibration, these standard interfaces are 
used for calibrating parameters of the control system's 
software from within its model. 

25 • For log & replay, these standard interfaces are used for 
logging measured data onto the host for transparently 
replaying it later on to the modeling tool for animation 
and visualization. 

3 0 • Using the standard interfaces is possible on most 

relevant hardware systems (combination of target, host, 
and interconnection in between) , hence, no additional 
efforts for software adaptation or porting is needed. 
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• For simulation on the host or rapid prototyping targets 
as well as for ECU operation, the same standard 
interfaces eaft may be used. 

5 • Memory, run- time, and bandwidth overheads are avoided due 
to the use of available standard interfaces. 

Off-line debugging mcano devices , for instance, that during an 
on-line experiment, first the measured data is logged onto the 

10 host's memory or hard disk. Afterwards, the data is replayed 
in off-line mode to the modeling tool, imitating the 
previously connected rapid prototyping hardware or a running 
ECU. This can may be performed completely transparent to the 
modeling tool . Further common debug features enabled provided 

15 by this approach are single-step execution and model 
breakpoints, support by the modeling tool assumed. 



In Figure 7 the Modeling Tools 70a and 70b and optional the 
M&C Tool 71 are ohown illustrated . Between these Modeling 

20 Tools 70a and 70b and optional 71 a and the target 80 a model 
animation interface 72 is situated. A target server 73 with 
protocol drivers 74 (e.g. CCP 74a, XCP 74b, KWP2000 74c, INCA 
74d, ASAP 74e, Distab 74f, usw.) or similar is connected to 
the physical interconnection 75. The standard M&C interface 76 

25 in the Target 80 connects this physical interconnection 75 to 
the Models 77a and 77b. On the target or the target processor 
as at least a part of the control system under development the 
application SW is executed. This architecture is one example 
for an inventive simulation system. Several architectures 

3 0 underlying the generic model animation and in-model 

calibration approach may be conceived of provided . As an 
example, this Target Server based approach is described in the 
following. Its main component is the Target Server running on 
the host computer and building the bridge between the modeling 

35 tools on the host and the target hardware. 
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Alternatively Lo a single target connected with one physical 
interconnection, several different hardware targets connected 
via diverse communication channels are conceivable possible , 
5 constituting a distributed system. Further, each modeling tool 
could may be used for animation and calibration of any number 
of models on the target at a time. 

The Function 

10 

The Target Server 

The Target Server is the central component of the generic 
model animation and in-model calibration approach. Its role is 
15 that of target hardware and communications abstraction. The 
main task of the Target Server is to connect the modeling 
tools with the target hardware's M & C interface in a 
transparent manner . 

20 Like this, the modeling tools need not be aware of the 

respective hardware used as target or of the communication 
protocols or physical interconnections being used as 
host/target interface. For this purpose, the Target Server may 
contain include a dedicated protocol driver or similar for 

2 5 each supported communication protocol, in order to perform the 
translation from model animation related communication into M 
& C specific protocols. 

Another task of the Target Server is to log measured data onto 
30 the host's memory or hard disk, in order to use it for off- 
line debugging replay later on. 

The Modeling Tools 
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The modeling tools access the Target Server via its model 
animation interface. Like this, data needed for animating the 
model is passed from the target to the modeling tool. Further, 
calibration data is passed in the other direction from the 
5 modeling tool down to the target hardware. Basic model 
animation and in-model calibration are available in the 
modeling tool as soon as it uses the Target Server for target 
access instead of proprietary communication protocols. For 
advanced log & replay features such as single-step debugging 
10 and model breakpoints, the modeling tool is assumed to provide 
addi t i ona 1 f unc t i ona 1 i t y . 

The M & C Tool 

15 An M & C tool could may run in parallel to the modeling tools, 
using the very same M & C interfaces and communication 
channels. However, this is no prerequisite for generic model 
animation and in-model calibration but depicted for 
demonstrating the conventional M & C approach. 

20 

In case multiple (modeling or M & C) tools simultaneously 
attempt to calibrate one and the same set of parameters, an 
arbitrage scheme must he used for safety and data consistency. 
This arbitrage scheme could may employ one or more of the 
25 following techniques, for instance: 

• locking of all but one tool for calibration of the given 



parameter net (master/slave principle), e.g 
read only parameters, 



by using 



30 



notification of all other tools after calibrating 
parameters of the given set, or 



35 



parameter refresh by all affected tools via periodic 
measurement of the given parameter set (polling) . 
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The Application Software 



The application software running on the target mainly consists 
5 of the models 1 code, a real-time operating system or a 

scheduler invoking the model code, hardware and communication 
drivers enabling model input and output, etc. The code 
generated from the models being simulated performs 
computations according to the models 1 specified behavior. The 
10 data structures in the code are accessed (read and write) by 
the standard M & C interface in order to perform conventional 
measurement and calibration or model animation and in-model 
calibration, respectively . 



15 The Standard M & C Interface 



The standard M & C interface on the target constitutes the 
link between application software and the Target Server. It 
accesses model data for measurement and calibration and is 
20 connected via the physical interconnection with the host. 

• For measurement, the M & C interface reads data from the 
application software and passes it via the M & C protocol 
to the Target Server which routes it to the modeling 

25 tools and the M & C tool (if applicable) . 

• For calibration, a modeling tool or the M & C tool sends 
new parameter values via Target Server and M & C protocol 
to the M & C interface which updates them in the 

30 application software on the target. 

As standard M & C interface, for instance, the CCP, XCP, 
KWP200O, INCA, or ASAPlb protocols could may be used, based 
on, e.g., CAN, Ethernet, FlexRay, USE, or K-Line as physical 
35 interconnection . 
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Alternatives 
Decentralized Approach 

5 

Instead of using a central Target Server component, each 
modeling and M & C tool could incorporate the host -side M & C 
interface adaptation on its own. Like this, the abstraction 
from target hardware could may still maintained, while the 
10 abstraction from communication channels would may be 
transferred to the tools involved. 

For this reason, target access would may be less transparent, 
and the number of M & C interfaces being supported could may 
15 be smaller. Further, the support of log & replay off-line 

debugging would may be more expensive. On the other hand, not 
all modeling and M & C tools would may need to comply with one 
and the same interface of a Target Server component as 
otherwise . 

20 

M & C Tool Interface Approach 

Instead of having modeling tools directly access the Target 
Server, an M & C tool could may be used as intermediary. For 

25 this, the model animation interface would may not be 

incorporated in the Target Server but in the M & C tool, e.g., 
an experiment environment for rapid prototyping. The modeling 
tools would may then connect to this interface. This approach 
could may more easily provide support for calibration 

30 arbitrage since 

• in general only the M & C tool and a single modeling tool 
compete in calibrating the same sets of parameters, and 
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• the M & C tool could may receive calibration commands 
from the modeling tool, interpret them for its own 
purposes (refresh of displayed value, data storage, 
etc.), and pass them to the Target Server for the actual 
5 calibration process. 
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Abotract 
ABSTRACT 

A simulation system and method are for computer- implemented 
simulation and verification of a control system under 
development, the simulation system comprioing including a 
generic model animation and in-model calibration interface, 
which uses measurement and calibration technologies with a 
host -target architecture, whereby the host containo includes 
at least one respective modeling tool and on the target 
software of the control system is executed. 

(Figure 7) 
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